Google Calendar adds free/busy scheduling

Just stumbled across the button “Check guest and resource availability” when adding a new appointment in Google Calendar. Sure enough, when clicked, a nice little window pops up that allows you to find slots of free time in common across invitees. Not sure if this is available across all of Google Calendar or if this is a Google Apps Premium feature (I’ve had imurdock.com in GAFYD for a while now and upgraded over the weekend). One problem is immediately apparent though: It only appears to be checking the main calendar (I actually have several calendars—work, home, travel, etc.). This is a problem with the SMS interface too, which only appears to operate on the main calendar.

You do back up your data regularly, don’t you?

Phil Wainewright: “So here is a selection of news stories culled from the past few months that allow us to objectively evaluate what happens when users ‘have total control over things like privacy and security’… […] Would any of those laptop thefts made the headlines had the data been stored in Google Apps? No, of course not, because the data would have remained inaccessible on Google’s servers.”

Great points. A little closer to home, how many times have you taken a call from an anguished family member who has just lost their data but who hasn’t heeded your advice to back up said data periodically? While we’re at it, how many times have you not heeded your own advice on the same subject? Could the SaaS providers possibly do any worse than we’ve been doing here? Granted, there needs to be a culture change, one that needs to happen on both sides of the transaction, to make this work. But it will eventually happen, because it Just Makes Sense.

Comments Off on You do back up your data regularly, don’t you?

Microsoft and the innovator’s dilemma

Henry Blodget: “Google’s current offerings–Gmail, Docs & Spreadsheets, etc.–bear all the markings of a classic disruptive technology. As Harvard professor Clayton Christensen observed, disruption begins when a dominant market leader has built so much functionality into its core products that it has begun to over-serve its core customers. Some of these customers, realizing that a simpler, cheaper product will do, abandon the old technology. At first, this does not concern the incumbent, as it maintains a chokehold on the highest margin business–the high-end customers who need most of that complicated functionality and support. But, gradually, as the lower end product gets better, and the incumbent is forced to migrate to even more complex and expensive solutions, more of the overall customer base defects. And, then, voila, one day the incumbent wakes up and discovers that it is DEC, Sears, or AOL…and by then it’s far too late to do anything about it.”

Why Solaris should adopt GPLv2

One word: Device drivers. (Ok, that’s two.)

One of the biggest problems for any developer building an operating system for the x86 is device support—how do you get your cool new OS to run reliably across the seemingly endless collection of hardware that is “the x86”? No matter how cool it is, it won’t seem very cool if it can’t talk to the hardware.

One time honored technique (at least in the academic world, and at least since I joined that world in the mid-1990s) is to use Linux’s huge collection of device drivers. Typically, that means creating a shim so your kernel can talk to the Linux device driver layer and, of course, making sure the licenses are compatible.

Not sure I understand the rationale behind GPLv3, since there are rumblings that v2 and v3 won’t be compatible, and since it doesn’t look like Linux is going to adopt v3 anytime soon. But Solaris adopting GPLv2 makes a whole lot of sense from my point of view just for the device drivers and the resulting boost to overall usability.

Yet more on the importance of backward compatibility

David Berlind: “With barely five days to go before long-anticipated January 30 launch of Vista is history, a familiar problem and the linchpin to adoption of any major operating system upgrade (Windows Vista qualifies) is crashing the party: backwards compatibility. Intuit, developer of one of the world’s most popular accounting applications used in small, medium and large businesses (Quickbooks), has notified its customers by email that Windows Vista is incompatible with some of the features of Quickbooks 2006.”

Mary Jo Foley: “Is it Intuit’s fault that its older products don’t work on Vista? Or Microsoft’s fault for changing the operating system in a way that it breaks them?”

George Ou: “As it turns out, it isn’t QuickBooks 2006 itself that has the problem with Vista but all the Intuit and third party add-on software that communicates with QuickBooks 2006 that’s the problem. More to the point, it’s the intercommunication between all those applications and the fact that they’re using forbidden techniques that have been banned since 2001 with Windows XP certification requirements that’s the issue. Intuit admitted to me that they declined to seek Windows XP certification for all these years and they’re just now making the necessary modifications for QuickBooks 2007. The reason this is relevant is because most software that is certified for Windows XP will automatically be compatible with Windows Vista.”

David Berlind: “So, while Microsoft’s response doesn’t point the finger directly at Intuit as the culprit in this situation, it makes it clear that its certification programs — programs that Intuit has apparently eschewed since 2001 — are the centerpiece of its efforts to guarantee backwards compatibility.”

Interesting discussion. Whose fault is it? It doesn’t really matter, as the end result is the same—Microsoft potentially loses customers (those who won’t upgrade to Vista because QuickBooks will break), and Intuit potentially loses customers (those who won’t upgrade to QuickBooks 2007 but rather will move to an on demand solution like NetSuite—customers tend to dislike forced upgrades).

David Berlind’s observation is interesting though, namely that Microsoft has been using its certification programs to limit the scope of the backward compatibility problem to a well defined subset around which it can presumably do thorough compatibility testing. Note that Red Hat too only guarantees backward compatibility for a subset of its platform, and that the LSB doesn’t cover the entire Linux platform either, just the subset that’s import for application portability.

What are the lessons here, from my point of view? First of all, and not surprisingly, backward compatibility matters, and it matters (or should matter) to both sides. Second, to achieve that backward compatibility, both sides have to work at it, and because a typical platform has so many moving parts, limiting the scope is key to understanding the “contract” between OS and application. Finally, some formal way of stating “I am following the contract”, such as a certification program, can make compatibility a lot easier to articulate to mutual customers.

Related: On the importance of backward compatibility, More on the importance of backward compatibility